As described in U.S. Pat. No. 5,689,708; in historical mainframe computer systems, a single central processor complex running under an operating system would execute application programs, stores databases, enforce security, and allocates all resources such as processor time, memory usage, and subsystem processing. Users would interact with the system via “dumb” terminals, which essentially only display data and receive keystrokes.
Evolution of networking connectivity and processor availability led to peer-to-peer networks of systems such as personal computers which are essentially standalone computers each running similar operating system programs, which can share application programs and data among each other according to a defined protocol.
Yet another form of computing deployment is that of client/server networks which have a central server computer coupled via a communications medium to a number of client computers, usually smaller personal computers running under a conventional operating system. In the earliest client/server network model, the server was only a “file server” which could download data to the clients and upload data from them; application programs were executed entirely in the client computers.
Most present client/server networks implement a more sophisticated “application server” model in which some or all application programs are split into two portions. A server portion executes within the server computer, while a separate client portion executes within each client computer from which a user can invoke the application. The two portions employ cooperative processing to pass data between the server and client computers; typically, most of the data is stored in the server. The first major application of this model was the processing of client queries against a central database, so that this model is also sometimes known as a “database server” network.
A key operational aspect which must be handed in such networks involves establishing authorization for access to data and services on the server by a given client. Authorization/permission control frameworks and relationships may be complex. Actions assigned to or requested by different components of such framework can be configured independently and separately by different entities: end user, application, AAA (Authentication, authorization and accounting) server, database, application server, firewall, network administrator, and other like network resource equipment.
At the time of actual performing of its actions, a given user's application (client-application) may communicate with another “application-aware” network entity which controls the permissions assigned to this application or user. This network entity could be some kind of Configuration server, Kerberos-like server, SBC (Session Border Controller), firewall, database, IPS (Intrusion Prevention System), Proxy server, or similar resource providing entity. This inter-application communication will operate using some form of communication protocol, API or other means.
The client-application, however, will also have its own independently defined settings which describe the actions this application is assumed (or expected by the user) to perform, i.e. things it is configured to do. At the time of execution these “local” settings may conflict with those permissions set by server-application. As a result of this, the client-application's request/action will not have permissions or authorization to be executed on (or approved by) the external entity. This results in the request/action denial by that external entity.
Denial of action may take various forms:
1. Rejection at application level and by the server application means
1.1 A “not authorized” application response—once extra credentials have been explicitly asked and (re)submitted
1.2 A “cancellation” of the transaction
1.3 A “bad/unrecognized request” type of application response
1.4 A redirection/forwarding to another external entity by means of the server application
1.5 An inducement of an error state or other security condition on the server side (external entity)
2. A client-to-server connection tear-down at the network Transport layer
3. A total lack of response
4. A partial provisioning—i.e. providing some minimal authorization/resources/access—yet not such as requested/expected/needed by the client application.
In general the settings' conflict may not be detected until the action is actually executed by application and the request for which insufficient authorization exists is communicated to the server. Moreover, and importantly, sometimes denial of action/request is unexpected by the client application in terms of software implementation (such as exceptions handling) or application logic. Given the variety of ways to deny the requested action (listed above), an unexpected denial may lead the application at the “client” side to enter into an unexpected state, for example that of termination, reboot, an infinite loop, crash, or freeze while waiting for further response. While application designers endeavor to anticipate and minimize such responses, the nature of software design does not render it inevitable that all such interactions are anticipated.
This is particularly evident in the live deployments of multi-user client applications, for example call centers, with the client application configurations periodically undergoing change by users/consumers, wherein there is no realistic way to make a “dry run” on all possible mismatch situations during configuration, deployment, or development/testing phases. Further, even if the client application is properly configured for a given server configuration, the permission settings on the server (network entity) are also subject to change due independent of the client application, which could potentially leads to a critical (for the client application) mismatch again.
Therefore, it would be desirable to obtain a networking implementation wherein authorization denials would be less likely to result in client-applications failing in an undesirable manner.